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BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

This invention relates to teleservice messaging in a wireless communication network. 
More particularly, the invention concerns a system and method for providing an indication of 
maximum teleservice payload size to a teleservice message sending entity in order to avoid 
resegmentation and retransmission delays. 

2. Description of the Prior Art 



Teleservice messaging is a form of conmiunication tliat allows information payloads (e.g. 
displayable text, graphics, executables, etc.) to be sent to mobile wireless communication devices 
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(e,g., cellular telephones) in manageable form. This type of messaging can be found in many 
species of wireless telecommunication systems, including those designed according to the 
TIA/EIA-41-D standard, the IS-2000 standard, the GSM standard, the UMTS standard, the IMT- 
2000 standard, and others. When a Mobile Station (MS), such as a wireless telephone, a wireless 
Personal Digital Assistant (PDA) or any other device capable of disseminating teleservice 
messages, is sent teleservice messages containing a payload by a network sending entity, such as 
a Short Message Service (SMS) Center (SMSC), a Message Center (MC), a Wireless Application 
Protocol (WAP) Server, or any other content provider, no regard is given to payload size 
constraints of the network receiving entities that serve the MS, such as the Mobile Switching 
Center (MSC), the Base Station (BS), or other entities. If one (or more) of the network receiving 
entities cannot handle the payload size, the network sending entity must be informed of the 
problem, and it must then resegment the payload into smaller information units and resend them. 
This causes delay and needlessly ties up network resources. 

Accordingly, a solution to the forgoing problem is required that enables teleservice 
payloads to always be sent in information unit sizes that can be accommodated by network 
receiving entities, such that message resegmentation and retransmission due to excessive payload 
size are avoided. 

SUMMARY OF THE INV ENTION 

The foregoing problems are solved and an advance in the art is obtained by a novel 
system and method for providing improved teleservice messaging to a mobile station in a 
wireless communication network. In accordance with the invention, an indication is provided to 
a network sending entity of the maximum teleservice payload size that can be sent by the 
network sending entity to the mobile station via network receiving entities serving the mobile 
station. The payload size indication is utilized by the network sending entity to format the size 
of teleservice messages sent by the network sending entity to the mobile station via the network 
receiving entities, such that resegmentation and retransmission are avoided. 

Network sending entities (e.g. SMSCs, MCs, WAP servers, etc.) that send teleservice 
layer messages containing a payload (e.g., displayable text such as SMS messages, displayable 
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text and graphics such as WML (WAP Markup Language) documents^ and executables such as 
WAP Java applets, etc) can thus be advised of the maximum payload size (e.g., in bits, bytes, 
data units, etc.) that can be handled by network receiving entities in the wireless network that 
serve a mobile station (e.g., MSCs, BSs, etc.), on a per message basis. This information is used 
by the network sending entity to appropriately segment the total payload into manageable 
packages (at the teleservice layer) prior to sending them on to the network receiving entities. 
This enables efficient use of transmission media and avoids retransmissions of correctly sized 
packages which otherwise may need to be done by trial and error. 

In preferred embodiments of the invention, the payload size indication is provided from 
one of the network receiving entities to the network sending entity. Most preferably, the payload 
size indication is provided from one of the network receiving entities to the sending network 
entity via a database associated with the mobile station. The receiving network entity providing 
the payload size indication could be an MSC acting as a voice communication switch on behalf 
of the mobile station. If data communication is involved, the receiving network entity sending 
the payload size indication could be a Mobile Data Intermediate System (MDIS) or a Serving 
GPRS Support Node (SGSN), The database could be the mobile station's Home Location 
Register (HLR). 

The payload size indication is preferably provided from one of the network receiving 
entities to the database as a message parameter during standard registration message exchange 
between the network receiving entity and the database during operations of the wireless network. 
Similarly, the payload size indication is preferably provided from the database to the network 
sending entity as a message parameter during routine registration message exchange between the 
database and the network sending entity. 

BRIEF DESCRff TION OF THE DRAWING 

The foregoing and other features and advantages of the invention will be apparent from 
the following more particular description of preferred embodiments of the invention, as 
illustrated in the accompanying Drawing, in which: 
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Fig. 1 is a functional block diagram showing a wireless communication system 
constructed in accordance with the invention; 

Fig. 2 is an information flow diagram showing an AuthenticationRequest operation using 
a maximum teleservice payload size indicator in accordance with the invention; 

Fig. 3 is an information flow diagram showing a FeatureRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 4 is an information flow diagram showing a LocationRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 5 is an information flow diagram showing an OriginationRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 6 is an information flow diagram showing a QualificationRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 7 is an information flow diagram showing a RegistrationNotification operation using 
a maximum teleservice payload size indicator in accordance with the invention; 

Fig. 8 is an information flow diagram showing an SMSNotification operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 9 is an information flow diagram showing an SMSRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; and 

Fig. 10 is an information flow diagram showing a TransferToNumberRequest operation 
using a maximum teleservice payload size indicator in accordance with the invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



Turning now to the figures, wherein like reference numerals represent like elements in all 
of the several views, Fig. 1 illustrates a functional representation of an exemplary wireless 
communication system 2 constructed in accordance with preferred embodiments of the invention. 
Fig. 1 is intended to be generic in nature and not limited to any particular wireless network 
standard. Indeed, the wireless system 2 may be implemented usmg any of the wireless network 
standards now in existence, such as TIA/EIA-41-D, IS-2000 or GSM, or which may be adapted 
in the future, such as UMTS, IMT-2000 or the like. Moreover, as described below, the wireless 
system 2 may be adapted to carry voice traffic, data traffic or both. 

As is known in the art, the wireless system 2 includes a plurality of wireless service areas, 
each of which is managed by the usual wireless network serving entities, mcluding an MSG and 
one or more BSs. Fig. 1 illustrates two wireless service areas that are respectively managed by 
the MSG 4 and the MSG 6. Associated with each MSG ai'e the usual Home Location Register 
(HLR), Visitor Location Register (VLR), Authorization Genter (AG) and Equipment Identity 
Register (EIR), all of which, with the exception of the invention-related enhancements described 
below, are conventional in nature. In Fig. 1, it will be seen that the MSG 4 is associated with an 
HLR 8, a VLR 10, an AG 12 and an EIR 14, and that the MSG 6 is associated with an HLR 9, a 
VLR 11, an AC 13 and a EIR 15. 

As is further known in the art, each MSG supports a plurality of BSs, each of which 
conducts wireless communications in an assigned geographic coverage area commonly referred 
to as a cell. Fig. 1 illustrates two such BSs; namely, the BS 16 connected to the MSG 4 and the 
BS 18 connected to the MSG 6. Each BS includes radio transceiver equipment for 
communicating in conventional fashion over an air interface with a plurality of MSs, which 
could be cellular telephones, wireless computing devices such as PDAs, or other radio 
communication equipment. Fig. 1 illustrates two such MSs; namely, the MS 20 communicating 
with the BS 16 and the MS 22 communicating with the BS 18. 
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In the wireless network 2, the MSCs 4 and 6 act as switching nodes for respectively 
communicating voice traffic on behalf of the MSs 20 and 22 over the circuit-switched PSTN 23. 
In association with the usual data network gateway equipment (not shown) the MSCs 4 and 6 
may also communicate voice traffic (VoIP) over the public Internet 31. The wireless network 2 
may also be adapted to carry data traffic (e.g., over the Internet 31) on behalf of MSs that are 
equipped for wireless data communication. There are several wireless data standards in use 
today, with the most prevalent being the Cellular Digital Packet Data (CDPD) and General 
Packet Radio Service (GPRS) standards. 

The wireless network 2 can be adapted to implement the CDPD standard by adding a 
plurality of Mobile Data Base Stations (MDBSs) and a Mobile Data Intermediate System switch 
(MDIS) m one or more of the wireless service areas. These entities are analogous to, and are 
typically associated with, the existing voice-oriented BSs and MSCs. The MDBSs communicate 
with the MSs over an air interface and the MDISs provide connectivity to a data network, such as 
the Internet 31. Thus, in Fig. 1, the wireless network 2 may include an MDBS 24 associated 
with the BS 16, and an MDBS 26 associated with the BS 18. Likewise, the wireless network 2 
may include an MDIS 28 associated with the MSC 4 and an MDIS 30 associated with the MSC 
6, each of which connect to the Internet 3 1. In combination, the MDBS 24 and the MDIS 28 
provide data communication support on behalf of the MS 20, while the MDBS 26 and the MDIS 
30 provide data communication support on behalf of the MS 22. 

The wireless network 2 can be adapted to implement the GPRS standard by adding a 
plurality of Serving GPRS Support Nodes (SGSNs) and a Gateway GPRS Support Node 
(GGSN) in one or more wireless service areas. Each SGSN is typically connected to a voice- 
oriented or packet data-oriented BS and MSC, and each GrGSN is usually connected to a data 
network, such as the Internet 31. Thus, in Fig. 1, the wireless network 2 may include an SGSN 
32 and GGSN 34 associated with the wireless service area managed by the MSC 4, and an SGSN 
36 and GGSN 38 associated with the wireless service area managed by the MSC 6. In 
combination, the SGSN 32 and the GGSN 34 provide data communication support on behalf of 
the MS 20, while the SGSN 36 and the GGSN 38 provide data communication support on behalf 
of the MS 22. 
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As is conventional, the MSs 20 and 22 have teleservice messaging capability, which 
allows them to retrieve teleservice payloads from a Network Sending Entity (NSE) 40 that 
communicates with the MSs via receiving network entities in the wireless network 2, such as the 
MSCs and the BSs. The NSE 40 could be any network sending entity supporting any service 
that requires the sending of large blocks of information requiring segmentation in order to be 
delivered to the MSs. For example, the teleservice messages sent by the NSE 40 could include 
SMS messages, Unstructured Supplementary Service Data (USSD) messages, Circuit Switched 
Data (CSD) messages, CDPD messages and GPRS messages. More specifically, one kind of 
network sending entity that could be represented by the NSE 40 is an SMS Message Service 
Center (SMSC) sending SMS messages. An SMSC acting on behalf of the MSs 20 and 22 could 
provide teleservice messages to the MSs that pertain to communications received from the PSTN 
23 (e.g., voice mail messages), the Internet 31 (e.g., email messages), and/or from other sources, 
such as a paging network 42 (e.g., paging messages). These messages would typically be 
provided to the MSs 20 and 22 via the intelligent network (e.g., SS7) portion 44 of the PSTN 23. 
Another network sending entity that could be represented by the NSE 40 is an Over-The- Air- 
Function (OTAF) used for provisioning wireless service (e.g., activating subscribers), 
downloading Preferred Roaming Lists (indicating the systems from which a roamer would prefer 
to receive service), and other functions. Still another netv/ork sending entity that could be 
represented by the NSE 40 is a WAP server operating in accordance with the WAP standard. 

In general, the network receiving entities that serve the MSs will vary depending on the 
message source and type. Circuit-based teleservice layer messages would normally be 
distributed to the MSs through the MSCs and the BSs. Packet-based teleservice layer messages 
may be distributed to the MSs through the MDISs (for CDPD data), or the SGSNs (for GPRS 
data), together with the BSs. 
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As stated, the network sending entities used in prior art wireless network systems format 
teleservice layer messages without knowledge of payload size constraints in the network 
receiving entities serving the mobile stations. The solution provided in accordance with 
preferred embodiments of the present invention entails the inclusion of an attribute in standard 
wireless network registration messages (e.g., a RegistrationNotification message according to the 
TIA/EIA-41-D standard) that allows the network sending entity to determine the maximum 
teleservice payload size that can be handled by the receiving network entities (e.g., MSCs, BSs, 
etc.). These standard registration messages that are modified to incorporate a teleservice payload 
size attribute include (1) registration messages that are first exchanged between a network 
receiving entity serving an mobile station (e.g., an MSG) and a database associated with the 
mobile station (e.g., an HLR), and (2) registration messages that are thereafter exchanged 
between the database and the network sending entity. More particularly, the first group of 
registration messages provide the teleservice payload size information fi-om the serving network 
receiving entity to the database, where the information is stored, and the second group of 
registration messages provide the teleservice payload size information from the database to the 
network sending entity. The network sending entity will then be able to use this information on 
large messages in order to segment them into units of appropriate size. 

To illustrate, consider the wireless telecommunication system of Fig. 1 wherein network 
entities, such as the MC 32, an MSG 4 or 6, a BS 16 or 18, and an HLR 8 or 9 (among others) are 
involved in providing voice services to a network subscriber operating one of the MSs 20 or 22. 
In that case, when the subscriber powers-on the MS, roams to a new service area (MSG/BS), 
originates a call, responds to a page for an incoming call, or in any other way accesses the 
wireless network 2, a registration process typically ensues. Registration results in the serving 
MSG informing the HLR assigned to the MS of the MS's presence in its sphere of influence. 
The HLR retains this information and will in turn forward the information upon request to the 
MC 32, so that the MC can forward incommg messages to the target MS 20 or 22, as in the case 
of mobile-terminated SMS. 
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Following are specific examples illustrating how teleservice payload size information can 
be provided to an NSE. All of the examples below are based on conventional registration 
messages currently in use according to the TIA/EIA-41-D wireless network intersystem operators 
standard. Appended to certain of these messages is a TS_DataSize parameter that indicates the 
maximum teleservice payload size that can be handled in a wireless service area managed by an 
MSC, an MDIS or a GGSN. Advantageously, no special payload size queries or processing are 
required. The teleservice payload size information, which is equipment-specific, can be input at 
system deployment time by a system administrator into a parameter database of the type 
conventionally associated with MSCs, MDIS and GGSNs for storing basic operating 
information. 

In the following examples, the set of parameters shown in addition to the TS_DataSize 
attribute are not necessarily inclusive. They are set forth for the purpose of illustration only 
based on existing standards. Persons skilled in the art will appreciate that the parameters shown 
may be augmented (or altered) in the future. 

Example 1 — Authentication On Initial Access 

This operation scenario describes the successful use of an AuthenticationRequest 
operation to authenticate an MS, which is attempting initial access to a serving MSC. The MS is 
aware that authentication is required on all system accesses. The result of the operation is to 
allow access. As shown in Step "a" of Fig. 2, during the initial access attempt by the 
authentication-capable MS (not shown), the serving MSC 50 sends an AUTHREQ message to a 
serving VLR 52. This message contains the following parameters, all of which are conventional 
save for the TS_DataSize parameter, which is added in accordance with the invention: 
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Parameters 


Usage 


Type 


AuthReqParameters 1 : 


Set of parameters in AUTHREQ: 




[MIN] 


Served MS MIN. 


R 


[ESN] 


Served MS ESN. 


R 


riu^sPTrn 

Liviijv_/j.uj 






fPC SWT 


carriage services are used. 


o 


r /ti'("i»tV» ov\o1ai 1 1+1 1 

Loy&lCIIi^w'apaUlilllCoJ 


/\U.lllCIlLlCallUli CapaDlllLlCS Ol oerVIIlg 

MSC. 


T> 






IN. 


rTprm i n 3 1 Tvnftl 


Tdenfifies the radio freniiencv interface 
Standard supported by the associated MS 


R 


RAND 


Random number derived from MS-provided 
RANDC by Serving MSC. 


R 


AUTHR 


Authentication result provided by MS. 


R 


COUNT 


Value of CaliHistoryCount provided by MS. 


R 


TS DataSize 


Maximum size of Teleservice pavload 


O 









As shown in Step "b" of Fig. 2, the VLR 52 sends an AUTHREQ message to an HLR 54 
associated with the MS. The parameters are the same as in Step "a" of Fig. 2, but include the 
following conventional modifications: 



Parameters 


Usage 


Type 


[SystemCapabilities] 


Authentication capabilities of Serving 


R 




VLR. 




[PC__SSN] 


Serving VLR PC_SSN. Include if SS7 


0 




carriage services are used. 





As shown in Step "c'' of Fig. 2, the HLR 54 forwards the AUTHREQ message to an AC 
56 associated with the MS. The parameters are the same as in Step "b" of Fig. 2. 

In Step "d" of Fig. 2, the AC 56 determines that the MS should be allowed access and 
sends an authreq message to the HLR 54. The message parameters, all of which are 
conventional, are as follows: 
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Parameters 


Usage 


Type 


AuthReqParameters2 : 


Set of parameters in authreq: 




[CallHistoryCount] 


Event counter used for clone detection. 
Included if SSD is shared. 


0 


[RANDSSD] 


Random number for SSD generation. 
Included if a SSD update and a Unique 
Challenge to the MS should be initiated 
by the serving system. 


0 


[RANDU] 


Random number generated by AC to 
produce AUTHU. Included if a Unique 
Challenge to the MS should be initiated 
by the serving system. 


0 


[AUTHU] 


Expected MS response to Unique 
Challenge Order as calculated by AC. 
Included if a Unique Challenge to the MS 

oll\JLilU L/V lllitiClL^U. Uy Hit' Owl V 111^ j^Dtx-'lli. 


0 


[UpdateCount] 


Indicates that tiie COUNT update 
procedure should be initiated by the 


o 


NewSSDInfo: 


New SSD information: 




[Authentication- 
Algorithm Version] 


Include if SSD included to select 
authentication algorithm other than 
default. 


o 




INCW VdlU^ \JL V J_v±\. dllU jr\.\-y Oll£Ut/U Qt^vi^l 

data. May be included if the 
SystemCapabilities of the VLR include 
"CAVE execution" and AC 
administration policies allow distribution 
of the SSD. 


0 


NOSSD 


Indicates that previously provided SSD is no 
longer valid and should be discarded. 


o 



In step ''e" of Fig. 2, the HLR 54 fonvards the authreq message to the VLR 56. The 
parameters are the same as for step "d" of Fig. 2. 

In step of Fig. 2, the serving VLR forwards the authreq message to the MSG 50. The 
parameters are the same as in step d of Fig. 2, except that the SSD, AAV and NOSSD parameters 
are not included, as is conventional 
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Example 2 - Direct FeatureReouest With Call Routing 



This operation scenario describes a normal Featm-eRequest operation when the response 
from an HLR includes instructions for the serving system to set up a call. As shown in step "a" 
of Fig. 3, a feature code string (i.e., a string of digits including a feature code) received from an d 
MS (not shown) are included in a FEATREQ message and sent by a serving MSG 60 to an HLR 
62 associated with the MS. The message parameters, which are otherwise conventional, include 
a TS DataSize parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN 


R 


BILLID 


Call ID. Used for billing and redirection 
purposes when FEATREQ results in call 
routing. 


R 


DGTSDIAL 


Feature code string entered by served MS. 


R 


SENDERIN 


Identification nuimber of the sending node. 


R 


TRANSCAP 


Indicates the serving system's transaction 
capability at the current time. 


R 


OTFI 


Indicates the current feature activation 
status. 


0 


TS DataSize 


Maximum size of Teleservice pavload 


O 
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In step "b" of Fig. 3, the HLR 62 determines the appropriate feature treatment based on 
the received information and returns this in a featreq message. In this scenario, the response 
from the HLR 62 includes instructions for the serving system to set up the call The featreq 
message has the following conventional parameters: 



Parameters 


Usage 


Type 


FEATRESULT 


Feature request result. 


R 


TERMLIST 


Call termination information. 


R 


ACTCODE 


Treatment for served MS. If not included, 
treatment is based on FEATRESULT 
value. 


0 




not included, announcement is based on 
FEATRESULT value. 


0 


DMHData: 


Data for DMH recording purposes: 




[DMH_AccountCode- 
Digits] 


Include if applicable. 


0 


[DMH_AltemateBillin 
gDigits] 


Include if applicable. 


0 


[DMH^BillingDigits] 


Include if applicable. 


0 


[MobileDirectory- 


Include if applicable. 


0 


GRPINFO 


Information associated with group routing. 


0 


OTFI 


Indicates the current feature activation 
status. 


0 


PACADTO 


Indicates PACA priority level. 


o 


CARDGTS 


Calling subscriber's PIC. Include if 

applicable and if not specified within the 
TenninationList parameter. 


0 


ROUTDGTS 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 


TERMTRIG 


Indicates active termination trigger points. 


0 
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Example 3 - Successful Location Request 

This operation scenario describes a LocationRequest operation when the call treatment 
to route the call to a PSTN directory number. As shown in step "a" of Fig. 4, an originating 
MSC 70 sends a LOCREQ message to an HLR 72 associated with the MS (not shown). This 
association is made through the dialed MS address digits (which may not be the MIN). The 
message parameters, which are otherwise conventional, include a TS_DataSize parameter in 
accordance with the invention, as follows: 



Parameters 


Usage 


Type 


BILLID 


Call ID. Used for billing and redirection 
purposes when LOCREQ results in call 
routing. 


R 


OrigID: 


Originating MSC's identification information: 




[MSCID] 


Originating MSC MSCID. 


R 


[PC_SSN] 


Originating MSC PC_SSN. Include if SS7 
carriage services are used. 


0 


[SystemMyTypeCode] 


Originating MSC vendor identification. 


MBC 


DGTSDIAL 


Digits identifying called party. 


R 


TRANSCAP 


Indicates the originating system's transaction 
capability at the current time. 


O 


TAT 


TerminationAccessType identifying special 
access situations. Include if applicable. 


0 
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TS DataSize 


Maximum size of Teleservice payload 


O 









In step "b" of Fig. 4, the HLR 72 determines that the call shall be routed to a PSTN 
directory number and returns this information to the Originating MSG in the locreq message, 
having the following conventional parameters: 



Parameters 


Usage 


Type 


MIN 


Called MS MIN. 


R 


ESN 


Called MS ESN. 


R 


MSCID 


Serving MSC's MSCID. 


R 


ANNLIST 


List of tones or announcements to play. If 
not included, announcement is based on 
other parameters in response. 


0 


PSTNRoutinglnfo: 


Call routing information: 




[TerminationList] 


Network termination information. Include 
if TerminationList is allowed. 


0 


[Digits(Destination)] 


PSTN DN for use in call routing. Include 
if TerminationList is not allowed. 


0 


[RoutingDigits] 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 


[Digits(Carrier)] 


Called subscriber's PIC. Include if 

or*t>lir*Ql^lA qhH iftirif crtAf^ifi^^rl within tViP 
djjpiiL/uOiC ailu 11 iiui apcuiicui wiuiiii iiic 

TerminationList parameter. 


0 


DMHData: 


Data for DMH recording purposes: 




[DMH^AccountCode- 
Digits] 


Include if applicable. 


0 


[DMHAitemateBillin 
gDigits] 


Include if applicable. 


0 


[DMH_BillmgDigits] 


Include if applicable. 


0 


[Mobi leD irectory- 
Number] 


Include if applicable. 


0 


[DMH_Redirection- 
Indicator] 


Include if applicable. 


R 
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Example 4 - Successful OriginationReauest 

This operation scenario describes an OriginationRejquest operation when a call 
origination request is successful. As shown in step "a" of Fig. 5, dialed digits are included in 
ORREQ message and sent by a serving MSG 80 to an HLR 82 associated with an MS (not 
shown). The message parameters, which are otherwise conventional, include a TS DataSize 
parameter in accordance with the invention, as follows: 
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Parameters 


Usage 


Type 


BILLID 


Call ID. Used for billing and redirection 
purposes when ORREQ results in call 
routing. 


R 


MIN 


Served MS MIN. 


R 


ESN 


Served MS ESK 


R 


MSCID 


Serving MSG MSCID. 


R 


PC_SSN 


Serving MSG PC_SSN. Include if SS7 
carriage services are used. 


0 


DGTSDIAL 


Digits, entered by served MS, which identify 
the called party. 


R 


ORIGTRIG 


Indicates the origination trigger responsible 
for the operation invocation. 


R 


TRANSCAP 


Indicates the Sendng MSCs transaction 
capabilities at the current time. 


R 


TS DataSize 


Maximum size of Teleservice payload 


O 



The HLR 82 determines that the origination request be approved and returns routing 
instructions in the orreqeq message, containing the following conventional parameters: 



Parameters 


Usage 


Type 


TERMTRIG 


Termination trigger points currently active 
for the MS. Include if applicable. 


. 0 


ACTCODE 


Include if action to be performed is not 
implied through presence of other 
parameters. 


O 


ANNLIST 


List of tones or announcements to play. If 
not included, announcement is based on 
other parameters in response. 


0 


Routinglnfo: 


Call routing information: 




[TerminationList] 


Call termination information. 


R 


[RoutingDigits] 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 


[CarrierDigits] 


Calling subscriber's PIC. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 


DMHData: 


Data for DMH recording purposes: 
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[DMH_AccountCode- 
Digits] 


Include if applicable. 


0 


[^UiVJ-tl /\lLcrildlCl51illIl 

gDigits] 






PMH_BillmgDigits] 


Include if applicable. 




[DMH_Redirection- 
Indicator] 


Include if applicable. 


R 


[MobileDirectory- 
Number] 


Include if applicable. 


0 



Example 5 - Successful OualificationRequest 

This operation scenario describes a QualificationRequest operation when authorization is 
confirmed and no profile is requested. As shown in step "a" of Fig. 6, after determining that a 
roaming MS (not shown) is within its service area, a serving MSG 90 sends a QUALREQ 
message to its VLR 92. The MSG 90 may detect the MS's presence through autonomous 
registration, call origination, call termination (i.e. a page response following a call to the roamer 
port) or a service order. The message, which is otherwise conventional, includes a TS_DataSize 
parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


MSCID 


Serving MSC MSCID. 


R 


MYTYP 


Serving MSC vendor identification. 


MBC 


QUALCODE 


Type of request - validation only. 


R 


SYSACCTYPE 


Indicates the type of system access. 


R 


TRANSCAP 


Indicates the serving system's transaction 
capability at the current time. 


R 


TS DataSize 


Maximum size of Teleservice payload 


O 



If the MS had previously registered with the MSC 90 (or any other MSC within the 
domain of the VLR 92), the VLR 92 may take no further action other than to record the identity 
of the MSC 90 currently serving the MS and proceed to step "d" of Fig. 6. If the MS is unknown 
to the VLR 92, or if the information requested by the MSC 90 is not available at the VLR 92, the 
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VLR 92 sends a QUALREQ message to an HLR 94 associated with the MS, as shown in step 
"b" of Fig. 6. The message parameters are the same as in step "a" of Fig. 6, and also include the 
following additional conventional parameters: 



Parameters are as in Step-a, with the following modifications: 


Parameters 


Usage 


Type 


MYTYP 


VLR vendor identification. 


MBC 



In step "c" of Fig. 6, the HLR 94 determines that authorization can be granted to the MS 
and returns this indication to the VLR 92 in a qualreq message, containing the following 
conventional parameters: 



Parameters 


Usage 


Type 


AUTHPER 


Authorization confirmed indication with 
period of authorization. 


R 


HLRID [MSCID] 


HLR MSCID to key MS record against for a 
subsequent 

UnrehabieRoamerDataDirective. 


R 


MYTYP 


HLR vendor identification. 


MBC 



In step "d" of Fig. 6, the VLR 92 sends a qualreq message to the MSG 90 containing the 
same parameters as in step "c" of Fig. 6, with the following conventional modifications: 



Parameters 


Usage 


Type 


HLRID [MSCID] 


HLR MSCID. Include if received in Step-c. 


0 


MYTYP 


VLR vendor identification. 


MBC 



Example 6 - Successful RegistrationNotification 

This operation scenario describes a RegistrationNotification operation when confirmed at 
an HLR. A serving MSG determines that a roaming MS is within its service area. The serving 
MSG may detect the MS's presence through autonomous registration, call origination, call 
termination (i.e., a page response following a call to the reamer port) or a service order. As 
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shown in step "a" of Fig. 7, the serving MSC 100 sends a REGNOT message to its VLR 102. 
The message, which is otherwise conventional, contains a TS_DataSize parameter in accordance 
with the invention, as follows: 



Parameters 


Usage 


Type 


IDInfo: 


Set of identification parameters in 
REGNOT: 




[MIN] 


Served MS MIN. 


R 


[ESN] 


Served MS ESN. 


R 


[MSCID] 


Serving MSC MSCID, 


R 


[PC_SSN] 


Serving MSC PC_SSN. Include if SS7 
carriage services are used. 


0 


[LocationArealD] 


For paging served MS. Include if 
available. 


0 


[SystemMyTypeCode] 


Serving MSC vendor identification. 


MBC 


QUALCODE 


Type of qualification required. 


R 


SYSACCTYPE 


Type of system access. 


R 




oyalCXllo Uailoav,.'lliJIi t/apaUlHiy 




TERMTYP 


Identifies the radio fi-equency interface 


R 


AVTYP 


Indicates MS is unavailable for normal call 

UcUVcry, li appilCdDiC. 


0 


SMSADDR 


Temporary routing address of SMS 

oUDavilUCij 11 appiXCaUlO. 


0 


A iitliPTTrvr' 


Pammptf^rQ inplnrlpH if 5iiitVipntiP?tti'nn 

parameters ^^^ere requested by the Serving 
MSC but not received from the MS: 


o 




A iifViprttipnti ri*n p?m?iKilitip<; of QPTVino 

system. 




[ReportType] 


Report of missing authentication 
parameters. 




BORDACC 


Indicates that system access is in a border 
cell, as determined by local procedures. 


0 


TS DataSize 


Maximum size of Teleservice pavload 


o 








Accesslnfo: 


Subscriber's access information. Included if 
system access is in a border cell. 
Includes: 


o 


[ReceivedSignaiQuality] 


Raw received signal strength from MS for 
use in multiple access signal strength 
arbitration. 
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[ControlChannelData] 


Includes: DCC and CHNO of analog 






access channel for use in multiple access 






detection; 






CMAC for use in signal strength 






arbitration. 




[SystemAccessData] 


Indicates the Serving MSC and cell site 






for use in multiple access detection. 





The VLR 102 determines that either (a) the MS had previously registered with the MSC 
100 (or another MSC within the domain of the VLR) but the MS has been reported inactive by 
the VLR 102, (b) the MS is not known to the VLR 102, or (c) the requested information cannot 
be made available for the indicated MS, Under these conditions, in step "b" of Fig. 7, the VLR 
102 forwards the REGNOT message of step "a" of Fig. 7 to an HLR 104 associated with the MS, 
with the following additional conventional parameters: 



Parameters 


Usage 


Type 


[PC_SSN] 


Serving VLR PC^SSN. Include if SS7 
carriage services are used. 


0 


[MYTYP] 


Serving VLR vendor identification. 


MBC 



The HLR 104 determines that authorization can be granted to the MS. In step "c" of Fig. 
7, it returns the requested information to the VLR 102 in a regnot message containing the same 
parameters as in step "b" of Fig. 7, with the following conventional additions and modifications: 



Parameters 


Usage 


Type 


HLRID [MSCID] 


HLR MSCID to key MS record against for a 
subsequent 

UnreliableRoamerDataDirective. 


R 


MYTYP 


HLR vendor identification. 


MBC 



In step "d" of Fig. 7, the VLR 102 forwards the regnot message to the MSC 100 using the 
same parameters as in step "c" of Fig. 7, with the following conventional modification: 
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Parameters 


Usage 


Type 


MYTYP 


VLR vendor identification. 


MBC 



Example 7 - Successful SMSNotification 

This scenario describes the successful use of an SMSNotification operation, conveying to 
an SMSC the SMS_Address of an MS-based Short Message Entity (SME). The invoking 
Functional Entity (FE) such as an MSC, an HLR, etc., detects a change of an MS's status or 
location indicating the availability of an MS-based SME. As shown in step "a" of Fig. 8, the 
invoking FE 1 10 may send m SMSNOT message to the responsible SMSC 1 12. If the FE 1 10 
has a pending request for the address of an MS-based SME, it must respond. The message, 
which is otherwise conventional, includes a TS_DataSize parameter in accordance with the 
invention, as follows: 



Parameters 


Usage 


Type 


MIN 


Used to identify the MS. 


R 


ESN 


Used to identify the MS. 


R 


SMSADDR 


Temporary routing address that can be used 
to deliver one or more short messages to 
the indicated MS. 


R 


TS DataSize 


Maximum size of Teleservice pavload 


O 



As shown in step "b" of Fig. 8, the SMSC 112 confirms the receipt of the address by 
returning an smsnot message to the FE 110. 

Example 8 - Successful SMSRequest 

This scenario describes the successful use of an SMSRequest operation, resulting in the 
return of the SMS_Address of an MS-based SME to an SMSC. As shown in step "a" of Fig. 9, 
an SMSC 120 does not have the current network address of the indicated MS-based SME, and it 
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sends an SMSREQ message toward an HLR 1 12 associated with the MS (possibly using SCCP 
global title translation of the MIN). The message parameters are conventional: 



Parameters 


Usage 


Type 


MIN 


Used to identify the MS. 


R 


ESN 


Used to identify tJie MS, 


0 


SMSNOTIND 


Include if a notification of MS availability is 
not required. 


0 



If the HLR 122 has the current address of the indicated MS-based SME, an smsreq 
message in accordance with step "f of Fig. 9 is sent from the HLR 122 to the SMSC 120. 
Otherwise, as shown in step "b'' of Fig. 9, the HLR 122 forwards the SMSREQ message toward 
a VLR 124 serving the addressed MS-based SMB. The message parameters are the same as in 
step "a" of Fig. 9. 

In step "c" of Fig. 9, the VLR 124 forwards the SMSREQ message toward an MSG 126 
serving the addressed MS-based SME. The parameters are the same as in step "a" of Fig. 9. 

The MSG 126 returns an smsreq message to the VLR 124 indicating the current network 
address that can be associated with the indicated MS-based SME. The message parameters, 
which are otherwise conventional, include a TS_DataSize in accordance with the invention, as 
follows: 



Parameters 


Usage 


Type 


SMSADDR 


Temporary routing address that can be used 
to deliver one or more short messages to 
the indicated MS. 


R 


IS DataSize 


Maximum size of Teleservice payload 


O 



In step "e" of Fig. 9, the VLR 124 forwards the smsreq message to the HLR 122. The 
parameters are the same as in step "d" of Fig. 9. 

In step "f of Fig. 9, the HLR 122 sends the smsreq to the SMSC 120. The parameters 
are the same as in step "d" of Fig. 9. 
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Example 9 - Successful TransferToNumberReauest 

This operation scenario describes a normal TransferToNumberRequest operation. As 
shown in step "a" of Fig. 10, an originating MSG 130 sends a TRANUMREQ message to an 
HLR 132 associated with an MS (not shown), including an indication of the feature responsible 
for redirecting the call (e.g., CFB). The message parameters, which are otherwise conventional, 
include a TS_DataSize parameter in accordance with the invention, as follows: 



- 

Parameters 


Usage 


Type 


BILLID 


Originating BillingID, required to identify 
instances of Flexible Alerting 




MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


MSCIN 


Include for IS-41-C or later. 


0 


MYTYP 


Originating MSG vendor identification. 


MBC 


REDREASON 


Identifies reason for the TRANUMREQ, 


R 


TRANSCAP 


Indicates the originating system's 

transaction capability at the current time. 


R 


GRPINFO 


Information associated with group routing. 
Include if avsiilable 


0 


LEGINFO 


Identifies a leg in a multiple termination call. 
Include if available. 


0 
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TS DataSize 



Maximum size of Teleservice pavload 



O 



As shown in step "b" of Fig. 10, the HLR 130 determines the forward-to number for 
redirecting the call and returns this to the MSG 130 in a tranumreq message. The parameters of 
this message are as follows: 



Parameters 


Usage 


Type 


Jvu U Llilgllliu . 

[TerminationList] 

[Digits(Destination)] 

[Digits(Carrier)] 


Call routing infonnation: 

Network termination information. Include 
if TerminationList is allowed. 

PSTN DN for use in call routing. Include 
if TerminationList is not allowed. 

Called subscriber's PIC. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 
0 
0 


ACTCODE 


Include if action to be performed is not 
implied through presence of other 
parameters. 


0 


ANNLIST 


Listoftonesorainnouncementstoplay. If 
not included, announcement is based on 
other parameters in response. 


O 


TERMTRIG 


Termination trigger points currently active 
for the subscriber. Include if applicable. 


O 


GRPINFO 


Identifies the new leg in a multiple 

termination call. Include if applicable. 


0 


CNIinfoASCII: 

[CallingPartyNumber- 
Stringl] 

[CallingPartyNumber- 
String2] 

[RedirectingNumber- 
String] 

[CallingPartySubaddre 
ss] 

[RedirectingSubaddres 
s] 


CNI information including digits parameters 
in ASCII fonnat. Include as applicable: 

Calling number digits (network-provided), 
incl, Present£Ltion restriction information. 

Calling number digits (user-provided), 
incl. Presentation restriction information. 

Redirecting number digits, incl. 
Presentation restriction information. 

Calling number subaddress (user- 
provided). 

Redirecting number subaddress. 


o o o o o 


RNDGTS 


Redirecting number digits in BCD format. 
May include if call is to be redirected out 
of the Originating MSC. 


0 
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DMHData: 


Data for DMH recording purposes: 




[DMH_AccountCode- 
Digits] 


Include if applicable. 


0 


[DMH_^A]temateBillin 
gDigits] 


Include if applicable. 


0 


[DMH_BillingDigits] 


Include if applicable. 


0 


[DMHRedirection- 
Indicator] 


Reason for extending the incoming call. 
Include for recording purposes. 


R 


[MobileDirectory- 
Number] 


Include if applicable. 


0 



Accordingly, a system and method have been described for providing an indication of 
maximum teleservice payload size in a wireless communication system. While various 
embodiments of the invention have been disclosed, it should be apparent that many variations 
and alternative embodiments could be implemented in accordance with the invention. It is 
understood, therefore, that the invention is not to be in any way limited except in accordance 
with the spirit of the appended claims and their equivalents. 
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CLAIMS 

What is claimed is: 

1 , A method for providing improved teleservice messaging to a mobile 
station in a wireless communication netv^ork, comprising the steps of: 

receiving at a network sending entity m indication of the maximum 
teleservice payload size that can be sent by said network sending entity to said 
mobile station via network receiving entities serving said mobile station; and 

utilizing said payload size indication at said network sending entity to 
format the size of teleservice messages sent hy said network sending entity to 
said mobile station via said network receiving entities. 



2. A method in accordance with Claim 1 wherein said receiving step 
includes receiving said payload size indication from one of said network receiving 
entities at said network sending entity. 



3, A method in accordance with Claim 2 wherein said network receiving 
entity from which said payload size indication is received is a switch serving said 
mobile station. 



4. A method in accordance with Claim 3 wherein said switch is a Mobile 
Switching Center (MSC). 
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5. A method in accordance with Claim 3 wherein said switch is a Mobile 
Data Intermediate System (MDIS). 



6. A method in accordance with Claim 3 wherein said switch is a Serving 
GPRS Support Node (SGSN). 

7. A method in accordance with Claim 2 wherein said receiving step further 
includes receiving said payload size indication from one of said network receiving 
entities at said network sending entity via a database associated with said mobile station. 



8. A method in accordance with Claim 7 wherein said database is a Home 
Location Register (HLR). 



9- A method in accordance with Claim 1 further including preliminarily 
receiving said payload size indication at a database associated with said mobile station 
as a message parameter during standard registration message exchange between one of 
said network receiving entities and said database during operations of said wireless 
network, said preliminary receiving step being perfoimed prior to said receiving step. 



1 0, A method in accordance with Claim 9 wherein said receiving step further 
includes receiving said payload size indication from said database at said network 
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sending entity as a message parameter during standard registration message exchange 
between said database and said network sending entity. 



11. A system for providing improved teleservice messaging to a mobile 
station in a wireless communication network, comprising:: 

means for receiving at a network sending entity an indication of the 
maximum teleservice payload size that can be sent by said network sending 
entity to said mobile station via network receiving entities serving said mobile 
station; and 

means for utilizing said payload size indication at said network sending 
entity to format the size of teleservice messages sent by said network sending 
entity to said mobile station via said network receiving entities. 



12. A system in accordance with Claim 1 1 wherein said receiving means 
includes means for receiving said payload size indication from one of said network 
receiving entities at said network sending entity. 

13. A system in accordance with Claim 12 wherein said network receiving 
entity from which said payload size indication is received is a switch serving said 
mobile station. 
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14. A method in accordance with Claim 13 wherein said switch is a Mobile 
Switching Center (MSG). 



15. A system in accordance with Claim 13 wherein said switch is a Mobile 
Data Intermediate System (MDIS). 



16. A system in accordance with Claim 13 wherein said switch is a Serving 
GPRS Support Node (SGSN). 

17. A system in accordance with Claim 12 wherein said receiving means 
further includes means for receiving said payload size indication from one of said 
network receiving entities at said network sending entity via a database associated with 
said mobile station. 



1 8. A system in accordance with Claim 17 wherein said database is a Home 
Location Register (HLR). 



19. A system in accordance with Claim 1 1 further including means for 
preliminarily receiving said payload size indication at a database associated with said 
mobile station as a message parameter during standaid registration message exchange 
between one of said network receiving entities and said database during operations of 
said wireless network, and wherein said preliminary receiving means receives said 
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payload size indication at said database prior to said receiving means receiving said 
payload size indication at said network sending entit> . 



20. A system in accordance with Claim 19 wherein said receiving means 
further includes means for receiving said payload size indication from said database at 
said network sending entity as a message parameter during routine message exchange 
between said database and said network sending entity. 



21. A method for providing improved teleservice messaging to a mobile 
station in a wireless communication network, comprising the steps of: 

providing to a network sending entity an indication of the maximum 
teleservice payload size that can be sent by said network sending entity to said 
mobile station via network receiving entities serving said mobile station; and 

said maximum teleservice payload size indication being utilizable by said 
sending network entity to format the size of teleservice messages sent by said 
network sending entity to said mobile station via said network receiving entities. 



22. A method in accordance with Claim 1 wherein said providing step 
includes providing said payload size indication from one of said network receiving 
entities to said network sending entity. 
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23. A method in accordance with Claim 2 wherein said network receiving 
entity providing said payload size indication is received is a switch serving said mobile 
station. 



24. A method in accordance with Claim 3 wherein said switch is a Mobile 
Switching Center (MSG). 

25. A method in accordance with Claim 3 wherein said switch is a Mobile 
Data Intermediate System (MDIS). 



26. A method in accordance with Claim 3 wherein said switch is a Serving 
GPRS Support Node (SGSN). 

27. A method in accordance with Claim 2 wherein said providing step further 
includes providing said payload size indication from one of said network receiving 
entities at said network sending entity via a database associated with said mobile station. 

28. A method in accordance with Claim 7 wherein said database is a Home 
Location Register (HLR). 



29, A method in accordance with Claim ] wherein said providing step 
includes providing said payload size indication to a database associated with said mobile 
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station as a message parameter during standard registration message exchange between 
one of said network receiving entities and said database during operations of said 
wireless network. 

30. A method in accordance with Claim 9 wherein said providing step further 
includes providing said payload size indication from said database to said network 
sending entity as a message parameter during standaj-d registration message exchange 
between said database and said network sending entity. 



31. A system for providing improved teleservice messaging to a mobile 
station in a wireless communication network, comprising:: 

means for providing to a network sending entity an indication of the 
maximum teleservice payload size that can be sent by said network sending 
entity to said mobile station via network receiving entities serving said mobile 
station; and 

said maximum teleservice payload size indication being utilizable by said 
sending network entity to format the size of teleservice messages sent by said 
network sending entity to said mobile station via said network receiving entities. 



32. A system in accordance with Claim 1 1 wherein said providing means 
includes means for providing said payload size indication from one of said network 
receiving entities to said network sending entity. 
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33. A system in accordance with Claim 12 wherein said network receiving 
entity from which said payload size indication is provided is a switch serving said 
mobile station. 



34. A method in accordance with Claim 1 3 wherein said switch is a Mobile 
Switching Center (MSC). 

35. A system in accordance with Claim 13 wherein said switch is a Mobile 
Data Intermediate System (MDIS). 

36. A system in accordance with Claim 1 3 wherein said switch is a Serving 
GPRS Support Node (SGSN). 

37. A system in accordance with Claim 1 2 wherein said providing means 
further includes means for providing said payload size indication from one of said 
network receiving entities to said network sending entity via a database associated with 
said mobile station. 

38. A system in accordance with Claim 17 wherein said database is a Home 
Location Register (HLR). 



-35- 

39. A system in accordance with Claim 1 1 wherein said providing means 
includes means for providing said payload size indication to a database associated with 
said mobile station as a message parameter during standard registration message 
exchange between one of said network receiving entities and said database during 
operations of said wireless network. 



40. A system in accordance with Claim 19 wherein said providing means 
further includes means for providing said payload si2;e indication from said database to 
said network sending entity as a message parameter during routine message exchange 
between said database and said network sending entity. 



41 . In an wireless communication system, a method for providing improved 
teleservice messaging to a mobile station communicating through the wireless 
communication system, comprising the steps of: 

receiving at a network sending entity an indication of the maximum 
teleservice payload size that can be sent by said network sending entity to said 
wireless station via network receiving entities serving said mobile station; 

utilizing said payload size indication at said network sending entity to 
format the size of teleservice messages sent by said network sending entity to 
said mobile station via said network receiving entities; 

said receiving step including receiviiag said payload size indication from 
one of said network receiving entities at said network sending entity via a 
database associated with said mobile station; and 
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said receiving step ftirther including first receiving said payload size 
indication at said database and thereafter at said network sending entity during 
standard registration message exchange between one of said network receiving 
entities and said database, and between said database and said network sending 
entity, respectively, during operations of said wireless communication system. 



42. In an wireless communication system, a method for providing improved 
teleservice messaging to a mobile station communicgiting through the wireless 
communication system, comprising the steps of: 

providing to a network sending entity an indication of the maximum 
teleservice payload size that can be sent by said network sending entity to said 
wireless station via network receiving entities serving said mobile station; 

said payload size indication being utilizable at said network sending 
entity to format the size of teleservice messages sent by said network sending 
entity to said mobile station via said network receiving entities; 

said providing step including providing said payload size indication from 
one of said network receiving entities to said network sending entity via a 
database associated with said mobile station; and 

said providing step further including providing said payload size indication to 
said database and to said network sending entity during standard registration message 
exchange between one of said network receiving entities and said database, and between 
said database and said network sending entity, respectively, during operations of said 
wireless communication system. 
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ABSTRACT 



A system and method for providing improved teleservice messaging to a mobile 
station in a wireless communication network are disclosed. In preferred embodiments, 
an indication is provided to a network sending entity of the maximum teleservice 
payload size that can be sent by the network sending entity to the mobile station via 
network receiving entities serving the mobile station. The payload size indication is 
utilized by the network sending entity to format the size of teleservice messages sent by 
the network sending entity to the mobile station via the network receiving entities. 



-38- 



SEQUENCE LISTING 



Not applicable 



O 
m 
=P 
ffl 
o 

o 
w 

1^ 

0 

o 
o 






H 
Z 
Z) 

o 
o 

"of 

X 

Z) 

< 



< 
a: 

o 

-I— • 

CD 

'U 

Q. 
O" 

o 
en 

SI 

<, 

O 

Lll 

Ql 
X 



< . 



o 
o 

of 

X 

h- 

< 

"d 
z 

< 
on 

w 
i_ 

CD 

-I— » 

0 

E 

CO 
CO 

Q. 
O" 

o 

x: 

O 
LU 

q: 

X 

I- 

Z) 

< 



I 



O 



§1 

X 
< 



< 



CD 



Q 
■CO- 
CO 
O 
Z 

S 

Q 
CO 
CO 

I 

-Z 4 



2 
o 

CD 

£ 

CD 
CD 

a. 
a- 

CD 

a: 
"< 

LU 

a: 

X 
H- 
D 
< 



CM 
CO 
. i- . 

CD 
0 

E 

CD 

CD 
CL 

cr 

q: 
<^ 

0 



1 



3 
CD 



Eh 



Q 

CO 

cn 
O 



Q 

CO 
CO 

CD 



Csl 
CO 

0 

«t— « 
0 

E 

■ 2 

CD 
CL 
- U 



1 



0 

sz 
cr 

0 



3 
CD 



CM 
CO 

0 

0 

E 

CD 
&- 

CD 

cr 

0 

01 
< 

0 



CD 



1 



o 

I— i 



o 



CD 







Lu 




_l 




X 


i 




/ 













LU 
Q 

z 
m 

CO 

< 

Q 
CO 

I- 

o 

Q ^ 
D LL 



IJU ^ 



O 

LU 

q:: 




a: 
i- 

a: 

LU 

I- 

co 
I- 

Q 



O 
LL 
Z 

CL 



CO 

Q 



I- 
D 
O 

a: 

CO 



CO o 
-J Q 

z 

^ < 
< o 



CO 



LU 
Q 

O LU 



=) < 
CO O 



LU 

I- 
< 

LU 
0 



< 
Dl 

iL 



.CD 



Eh 



d 




00 



o 
oo 




_ C/3 
(D >> 

CO w 



CL 
< 

o 

CO 



o 

a: 
\- 

(D 

CL 
O 

-J 
< 

Q 
CO 
I- 
O 
Q 

Z 

CO 
CO 

I 

o 

Q. 

9 

o 

CO 



CO 
LU 



CQ 

O 
LLi 

a: 
q:: 
o 



CO 



1 



CO TO 

Zi Q 
Z I 

SI 
8^ 

O 
< 

o 



o 

a: 



(L 

LU 



0 



O 



I 



in 

d 




d 

h— I 
P-H 



E 

<]} 
■+-» 

CO 

c 
■> 

CO 




d 




CO 



o 
c 
(/) 

E 

C/) 



o 
m 
=c 
in 

0 
□ 

u 

O 

P 
O 

o 



Q 
Q 

< 

CO 
CO 



CO 
Lli 




o 

z 

CO 
CO 



Eh 
CO 



oo 

d 



CO 



o 



CD 





o 

Q o 
X 



CO 
UJ 



o 




h- 

o 



LU 



Q 
-Z 

H 

o 
z 

CO 
CO 



CO 
UJ 



■a 

LU 

a: 

CO 
CO 



Eh 

■ft; 

CO 



-Q ■ 

Q 

< 

CO 

CO 
C7 
CO 

E 

<n 



Eh 

•o; 

CO 



-Q ■ 

Q 

< 

CO 
CO 

CO 

£ 

CO 



CO 



a: 

-a ' 

Q 

< 

CO 

CO 
o- 

CD 

E 

CO 



d 
I— I 




o 



> 



Q. 



>- o 

z < 

— o 

O 00 

CO 
LU 



Q 



O 

LU 




LU 



CO 



CO 
h- 

O 
Q 



< = 

rO 



LU 



CO 



§1 

o z 
< o 

C LJ_ 
D)Z 

^0 

E 
c 



1 



Chander 6-5 



IN THE UNITED STATES 
PATENT AND TRADEMARK OFFICE 

Declaration and Power of Attorney 
As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to 
my name. 

I believe I am an original, first and joint inventor of the subject matter which is 
claimed and for which a patent is sought on the invention entitled SYSTEM AND 
METHOD FOR PROVIDING INDICATION OF MAXIMUM TELESERVICE PAYLOAD 
SIZE IN A WIRELESS COMMUNICATION NETWORK, the specification of which is 
attached hereto. 

I hereby state that I have reviewed and understand the contents of the above 
identified specification, including the claims, as amended by an amendment, if any, 
specifically referred to in this oath or declaration. 

I acknowledge the duty to disclose all information known to me which is 
material to patentability as defined in Title 37, Code of Federal Regulations, 1 .56. 

I hereby claim foreign priority benefits under Title 35, United States Code, 1 19 
of any foreign application(s) for patent or inventor's certificate listed below and have 
also identified below any foreign application for patent or inventor's certificate having 
a filing date before that of the application on which priority is claimed: 

None 

I hereby claim the benefit under Title 35, United States Code, 120 of any United 
States application(s) listed below and, insofar as the subject matter of each of the 
claims of this application is not disclosed in the prior United States application in the 
manner provided by the first paragraph of Title 35, United States Code, 112, I 
acknowledge the duty to disclose all information known to me to be material to 
patentability as defined in Title 37, Code of Federal Regulations, 1 .56 which became 
available between the filing date of the prior application and the national or PCT 
international filing date of this application: 

None 

I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and belief are believed to be true; and 
further that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, 
under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 
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I hereby appoint the following attorney(s) with full power of substitution and 
revocation, to prosecute said application, to make alterations and amendments 
therein, to receive the patent, and to transact all business in the Patent and 
Trademark Office connected therewith: 



Lester H. Birnbaum (Reg. No. 25830) 

Richard J. Botos (Reg. No. 32016) 

Jeffery J. Brosemer (Reg. No. 36096) 

Kenneth M. Brown (Reg. No. 37590) 

Donald P. Dinella (Reg. No. 39961) 

Guy Eriksen (Reg. No. 41736) 

Martin I. Finston (Reg. No. 31613) 

James H. Fox (Reg. No. 29379) 

William S. Francos (Reg. No. 38456) 

Barry H. Freedman (Reg. No. 26166) 

Julio A. Garceran (Reg. No. 37138) 

Mony R. Ghose (Reg. No. 38159) 

Jimmy Goo (Reg. No. 36528) 

Anthony Grille (Reg. No. 36535) 

Stephen M. Gurey (Reg. No. 27336) 

John M. Harman (Reg. No. 38173) 

Michael B. Johannsen (Reg. No. 35557) 

Mark A. Kurisko (Reg. No. 38944) 

Irena Lager (Reg. No. 39260) 

John B. Maclntyre (Reg. No. 41170) 
Christopher N. Malvone (Reg. No. 34866) 

Scott W. McLellan (Reg. No. 30776) 

Martin G. Meder (Reg. No. 34674) 

Geraldine Monteleone (Reg. No. 40097) 

John C. Moran (Reg. No. 30782) 

Michael A. Morra (Reg. No. 28975) 

Gregory J. Murgia (Reg. No. 41209) 

Claude R. Narcisse (Reg. No. 38979) 

Joseph J. Opalach (Reg. No. 36229) 

Neil R. Ormos (Reg. No. 35309) 

Eugen E. Pacher (Reg. No. 29964) 

Jack R. Penrod (Reg. No. 31864) 

Daniel J. Piotrowski (Reg. No. 42079) 

Gregory C. Ranieri (Reg. No. 29695) 

Scott J. Rittman (Reg. No. 39010) 

Eugene J. Rosenthal (Reg. No. 36658) 

Bruce S. Schneider (Reg. No. 27949) 

Ronald D. Slusky (Reg. No. 26585) 

David L. Smith (Reg. No. 30592) 
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Patricia A. Verlangieri (Reg. No. 42201) 

John P. Veschi (Reg. No. 39058) 

David Volejnicek (Reg. No. 29355) 

Charles L. Warren (Reg. No. 27407) 

Eli Weiss (Reg. No. 17765) 



I hereby appoint the attorney on ATTACHMENT A as associate attorney in the 
aforementioned application, with full power solely to prosecute said application, to 
make alterations and amendments therein, to receive the patent, and to transact all 
business in the Patent and Trademark Office connected with the prosecution of said 
application. No other powers are granted to such associate attorney and such 
associate attorney is specifically denied any power of substitution or revocation. 



Full name of 1st joint inventor: Sharat Subramaniyam Chander 

inventor's .^--^ A/'T^AK/^ 

signature ^ L^^-^ Date_ 



Residence: 4105 Nelson Court, Woodbridge, Illinois 60517 
Citizenship: USA 

Post Office Address: 4105 Nelson Court, Woodbridge, Illinois 60517 



Full name of 2nd joint inventor: Shiv Mohan Seth 

llignature ^ SWw Stjk Date ) / A / 

Residence: 1167 Black Stallion Drive, Naperville, Illinois 60540 
Citizenship: USA 

Post Office Address: 1167 Black Stallion Drive, Naperville, Illinois 60540 
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ATTACHMENT A 



Attorney Name: Walter W.Duft Reg. No.: 31,948 

295 Main Street, Suite 762 
Buffalo, New York 14203-2507 



Telephone calls should be made to Walter W. Duft at: 
Phone No.: (716) 856-8000 
Fax No.: (716) 856-8046 



All written communications are to be addressed to: 



Walter W. Duft 
295 Main Street, Suite 762 
Buffalo, New York 14203-2507 



